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The  O’Hare  Runway  Configuration  Management  System  (CMS)  is  an 
interactive  multi-user  computer  system  designed  to  aid  O'Hare 
management  personnel  in  the  consistent  selection  of  runway 
configurations  in  order  to  reduce  aircraft  delays.  CMS  is  also  used 
for  the  purpose  of  communicating  and  disseminating  information  about 
the  airport  among  the  tower  and  Terminal  Radar  Control  Facility 
(TRACON)  personnel. 

Although  the  CMS  software  was  written  for  O'Hare  International 
Airport,  it  can  be  adapted  for  other  airports  to  serve  as  an 
automated  planning  aid  for  runway  configuration  management.  This 
would  require  changing  the  associated  site  specific  adaptation 
data.  At  some  airports,  however,  the  need  might  be  to  manage  the 
surrounding  airspace  which  is  shared  with  other  airports,  or  to 
manage  the  flow  of  aircraft  on  taxiways  as  opposed  to  runway 
configuration  management.  The  basic  concepts  of  CMS  can  be  extended 
to  include  such  applications  as  well  but  would  require  site  specific 
model  development  to  suit  the  needs  of  the  individual  airport. 

The  purpose  of  this  report  is  to  describe  the  CMS  software  in  the 
time  sharing  environment  of  MITRE  Washington's  Computer  Center. 
Currently,  CMS  is  housed  in  an  IBM  4341  computer  with  VM/SP 
operating  system.  CMS  employs  the  IBM's  Display  Management  System 
(DMS)  software  package  that  provides  full  screen  menu  type 
displays.  The  display  terminals  used  by  CMS  are  IBM's  3270  series 
or  equivalent.  The  CMS  software  is  written  exclusively  in  PL/I  and 
complies  fully  with  top-down  structured  programming  techniques. 

CMS  has  been  designed  to  facilitate  manual  data  entry,  since 
automated  inputs  are  not  yet  readily  available.  CMS  is  available 
for  interactive  access  by  the  tower  and  radar  room  personnel  who 
normally  monitor  and  report  changes  in  the  airport  operational 
environment.  These  users  are:  the  Assistant  Chief  (AC),  who  has 
the  primary  responsibility  for  configuration  selection;  the  team 
supervisor  of  the  tower  cab  (CAB),  who  provides  operational 
information  (wind,  weather,  runway  conditions)  to  the  system;  and 
the  Airways  Facilities  operations  officer  (AF),  who  is  responsible 
for  the  runway  equipment  status.  The  interactions  between  these 
users  and  CMS  are  illustrated  in  Figure  A. 

Because  of  the  limitations  of  the  time-sharing  system  under  which 
CMS  is  currently  operating,  these  three  different  users  can  only  be 
supported  by  three  separate  programs.  These  programs  are  compiled 
and  stored  separately  and  operate  independently,  but  communicate 
through  a  common  data  base  which  contains  all  information  on  O'Hare 
status  over  the  planning  horizon.  When  CMS  is  implemented  at 
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FIGURE  A 

PHYSICAL  CONFIGURATION  OF  CMS 


O'Hare,  it  will  operate  on  a  dedicated  mini-computer  which  permits 
multi-tasking  (that  is,  multiple  users  interacting  with  a  single 
program  simultaneously).  This  will  eliminate  the  need  for  three 
separate  programs;  certain  changes  to  the  program  structure  will  be 
required  to  make  best  use  of  the  multi-tasking  environment,  but  the 
basic  CMS  logic  will  not  be  affected. 

Each  program  within  the  CMS  software  package  supports  a  set  of  data 
"screens",  each  containing  a  predetermined  subset  of  information  for 
input  or  display.  An  example  of  a  CMS  screen  is  given  in  Figure  B. 
Table  A  contains  a  list  of  display  screens  within  the  CMS  software. 
In  some  cases  there  is  an  overlap  of  Information  among  several 
screens.  Although  the  screens  are  not  mutually  independent  (i.e., 
changes  in  one  screen  may  affect  the  contents  of  the  others),  they 
are  self-contained  in  that  they  serve  a  specific  purpose  and  are 
acted  upon  separately. 

The  screens  provide  a  convenient  format  for  entering  data  on  the 
current  and  future  operating  environment  at  O'Hare.  This  includes 
Information  on  wind  speed  and  direction,  ceiling  and  visibility, 
runway  surface  conditions,  status  of  runway  landing  aids,  and  the 
expected  volume  and  distribution  of  traffic.  This  Information  is 
then  used  by  CMS  to  determine  the  operational  availability  of 
individual  runways.  The  operational  suitability  of  the  runway 
configurations  is  then  determined,  based  upon  runway  availability 
and  other  operational  factors;  and  the  configurations  are  ranked 
according  to  their  capacities,  based  upon  projected  demand  for  the 
next  hour.  The  penalty  of  transitioning  from  current  configuration, 
in  terms  of  capacity  during  the  transition  period,  is  also 
calculated  and  displayed.  This  yields  the  primary  output  of  the 
runway  configurations  management  system  —  an  ordered  list  of 
transition  strategies  indicating  which  runways  to  use  at  what  times 
during  the  planning  period. 

Volume  I  of  this  report  defines  the  major  subsystems  within  the  CMS 
software  package,  discusses  the  overall  control  and  architecture  of 
the  CMS  software,  and  describes  the  software  logic  pertaining  to 
each  component.  ’’High-level",  English-like  pseudocode  is  used  to 
describe  the  CMS  software.  Pseudocode  is  used  because  it  can 
provide  a  clear,  English-like  description  which  is  believed  superior 
to  flowcharts  for  conveying  complex  logic  to  the  reader,  while  still 
maintaining  a  formal  structure. 

Volume  II  contains  the  "low-level",  variable  specification 
pseudocode,  in  order  to  provide  a  detailed  description  of  the 
software. 
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FIGURE  B 

EXAMPLE  OF  CMS  SCREEN 


TABLE  A 

LIST  OF  INPUT/OUTPUT  DISPLAY  SCREENS 


1.  Menu  of  Program  Function  Keys  and  Program  Termination 

2.  Parameters 

3.  O'Hare  Status  Summary 

4.  Planning  Log  Selection 

5.  Wind  and  Weather  Planning  Log 

6.  Runway  Conditions  Planning  Log 

7.  Equipment  Planning  Log 

8.  Demand  Planning  Log 

9-10.  Airport  Status  (Current/Forecast) 

11-12.  Runway  Equipment  Status  (Current/Forecast) 

13-14.  Demand  Profile  (Current/Forecast) 

15-16.  Ordered  List  of  Configurations  (Current/Forecast) 

17.  Current  Departure  Queues 

18.  Ordered  List  of  Transitions 


19-20.  Configuration  Information  (Current/Forecast) 
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INTRODUCTION 


1.1  Purpose  and  Scope 

The  O'Hare  Runway  Configuration  Management  System  (CMS)  Is  an 
Interactive  multi-user  computer  system  designed  to  aid  the 
O'Hare  management  personnel  in  the  consistent  selection  of 
runway  configurations  in  order  to  reduce  aircraft  delays.  CMS 
is  also  used  for  the  purpose  of  communicating  and  disseminating 
information  about  the  airport  among  the  various  tower  and 
Terminal  Radar  Control  Facility  (TRACON)  personnel  (Reference  1). 

The  purpose  of  this  report  is  to  describe  the  CMS  software  as  it 
stands  in  the  time  sharing  environment  of  MITRE  Washington's 
Computer  Center.  In  these  documents  (Volumes  I  and  II) ,  the 
major  subsystems  within  the  CMS  software  package  are  defined  and 
the  software  logic  pertaining  to  each  component  is  described 
fully.  Also,  the  overall  control  and  architecture  of  the  CMS 
software  is  discussed. 

Additional  information  on  the  use  of  CMS  and  logic  details  may 
be  found  in  References  2  and  3. 

1.2  Use  of  Pseudocodes 


In  these  documents,  pseudocodes  are  used  to  describe  the  CMS 
software  in  detail.  The  pseudocode  approach  to  software 
documentation  is  adopted  because  it  provides  a  clear, 
English-like  description,  which  is  believed  superior  to 
flowcharts  for  conveying  complex  logic  to  the  reader,  while 
still  maintaining  a  formal  structure.  In  order  to  present 
different  levels  of  detail  to  all  readers,  two  types  of 
pseudocodes  are  used:  "high-level"  English-like  and  "low-level" 
variable  specification. 

There  exist  a  number  of  different  pseudocode  languages,  each 
suited  for  a  particular  application  or  style.  For  this  document 
the  pseudocode  language  "E"  or  "Eclectic”  was  chosen.  "E"  was 
developed  by  The  MITRE  Corporation  In  conjunction  with  the  Air 
Traffic  Advisory  and  Resolution  Service  (ATARS)  project  (Refer¬ 
ences  4  and  5).  The  decision  to  choose  "E”  was  made  based  on 
the  fact  that  "E"  is  designed  to  support  PL/I  programming 
language,  is  suited  for  structured  programming  style,  and  has 
readily  accessible  documentation.  Appendix  B  presents  a  brief 
summary  of  the  syntax  of  ”E"  language. 


1.3  Organization 

In  Volume  I,  a  brief  overview  of  CMS  is  presented  In  Section  2. 
Section  3  discusses  a  number  of  software  design  considerations 
and  limitations  associated  with  the  current  version  of  CMS.  The 
overall  structure  of  the  CMS  software  is  described  in  Section 
4.  Section  5  familiarizes  the  reader  with  the  CMS  data  base. 
Sections  6  and  7  present  the  logic  of  CMS  software;  the  former 
section  deals  with  system  data  structures  and  top  level  pro¬ 
cessing  while  the  latter  describes  individual  screens.  The 
logic  of  the  CMS  software  is  presented  in  the  form  of  high  level 
pseudocodes  in  Appendix  A.  Finally,  there  are  a  number  of  other 
Appendices  that  deal  with  topics  such  as  syntax  of  E  language, 
CMS  utility  programs,  PL/I  built-in  functions  used  in  CMS,  and 
data  base  format. 


In  Volume  II,  a  more  detailed  description  of  the  CMS  software  is 
presented  in  the  form  of  low-level  pseudocodes. 


CMS  OVERVIEW 


This  section  offers  an  overview  of  the  O'Hare  Configuration 
Management  System.  The  description  has  been  adapted  and 
summarized  from  Reference  1. 

The  O'Hare  Runway  Configuration  Management  System  (CMS)  is  an 
interactive  computer  program  designed  to  aid  the  combined  O'Hare 
tower/TRACON  facility  management  in  the  consistent  selection  of 
runway  configurations  in  order  to  lower  aircraft  delays. 

At  O'Hare,  the  process  of  runway  configuration  selection  is 
complex  because  of  the  runway  layout  (Figure  2-1)  and  the 
dynamic  nature  of  airport  operations.  There  are  twelve  main 
runway  ends  and  a  short  runway  (18/36)  which  is  used  solely  for 
general  aviation  traffic  under  visual  conditions.  Using  only 
twelve  main  runways,  O'Hare  personnel  have  Identified  seventy- 
three  operationally  feasible  runway  configurations  that  use  at 
least  two  arrival/departure  runway  pairs  simultaneously. 
Additionally,  there  are  a  great  number  of  runway  combinations 
that  include  fewer  runways.  Moreover,  O’Hare  is  one  of  the 
major  connectors  of  domestic  and  International  flights  causing 
significant  variations  in  the  volume  and  distribution  of  air 
traffic  over  each  of  its  arrival  and  departure  fixes. 
Furthermore,  rapidly  changing  weather  and  wind  conditions  in  the 
Chicago  area  further  complicate  the  process  of  runway 
configuration  selection.  The  above  mentioned  problems,  plus 
others  common  to  all  major  airports  such  as  runway  closures  and 
equipment  outages  make  CMS  a  useful  planning  aid  for  O'Hare. 

Today  at  O'Hare,  the  Assistant  C’:ief  (AC)  has  the  primary 
responsibility  for  configuration  ilection.  The  decision  on 
changing  runway  configurations  is  based  primarily  on  airport 
status,  equipment  status,  and  traffic  demand,  and  requires 
extensive  coordination  with  supervisors  of  the  tower  cab  and  the 
TRACON.  CMS  provides  the  means  to  consolidate  and  display 
information  relevant  to  this  decision  making  process.  Further¬ 
more,  CMS  automatically  Integrates  information  on  airport 
’status,  equipment  status,  and  traffic  demand  into  a  measure  of 
capacity  for  evaluating  different  configuration  choices,  as  well 
as  provides  the  AC  with  a  tool  In  planning  transitions  between 
the  currently  operating  configuration  and  the  set  of  feasible 
ones  under  forecast  conditions. 

The  elements  that  make  up  the  runway  configuration  management 
process  are  depicted  in  Figure  2-2.  The  initial  step  in  runway 
configuration  management  is  to  define  the  respective  current  and 
forecast  scenarios.  In  the  case  of  the  current  scenario,  this 
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FIGURE  2-1 

CHICAGO  O’HARE  INTERNATIONAL  AIRPORT 


CURRENT  CONDITIONS 


FORECAST  CONDITIONS 


is  accomplished  by  making  sure  chat  CMS  is  continually  updated 
with  all  changes  in  the  current  operating  environment.  In  the 
absence  of  automated  interfaces  with  monitoring  systems  in  the 
tower  and  TRACON  facilities,  the  updating  functions  of  current 
operating  conditions  can  be  delegated  to  those  who  now  have  the 
responsibility  for  monitoring  and  reporting  that  Information 
without  creating  additional  workloads.  Such  responsibilities 
today  lie  with  the  cab  team  supervisor  who  is  in  charge  of 
updating  weather,  wind,  and  runway  conditions  and  Airway 
Facilities  (AF)  operations  officer  who  maintains  the  runway 
equipment  status. 

On  the  other  hand,  the  forecast  scenarios  reflect  the  changes  in 
the  operational  environment  expected  to  occur  in  the  future  that 
may  be  substantial  enough  to  require  configuration  changes.  The 
responsibility  in  this  case  lies  with  the  AC  who  acquires  the 
forecast  conditions  and  expected  changes  through  a  system  of 
interconnected  planning  logs  communicated  to  him  by  other 
participants  (AF  operations  officer  and  cab  team  supervisors). 
Therefore,  the  AC  constructs  forecast  scenarios  from  actual 
forecast  conditions  or  other  hypothesized  situations  as  is 
deemed  necessary. 

The  next  step  in  runway  configuration  management  1b  to  determine 
the  operational  availability  of  individual  runways  and  subse¬ 
quently  configurations  within  each  scenario  (current  and 
forecast).  This  is  accomplished  by  runway  and  configuration 
eligibility  analyses  performed  by  CMS.  After  a  list  of  eligible 
configurations  is  determined,  CMS  performs  capacity  analysis  and 
produces  ordered  lists  of  configurations  based  on  capacity 
within  each  scenario. 

Finally,  the  last  step  in  runway  configuration  management  is  the 
transition  analysis.  CMS  combines  the  current  and  forecast 
scenarios  to  produce  an  ordered  list  of  transitions.  The 
transition  analysis  helps  the  AC  in  selecting  configurations 
that  have  lower  transition  penalties  and  high  capacities. 

A  proposed  CMS  hardware  configuration  consists  of  a  central 
computer  supporting  three  CRT  display  terminals  and  one  printer 
(Figure  2-3).  A  terminal  is  dedicated  to  the  AF  operations 
officer  and  another  to  the  supervisor  of  the  tower  cab,  while 
the  third  terminal  is  used  by  the  AC.  Each  terminal  allows  a 
selected  set  of  Inputs  into  CMS  consistent  with  the  information 
for  which  that  terminal  position  is  responsible  as  will  be 
defined  later  in  this  document. 


CMS  offers  a  number  of  other  benefits  in  addition  to  its  primary 
purpose  of  assisting  the  AC  in  runway  configuration  selection. 
The  use  of  multiple  terminals  to  access  a  common  central  data 
base  provides  the  facility  personnel  with  immediate  displays  of 
the  current  operational  status  of  the  airport.  The  multiple 
terminal  concept  also  allows  direct  communication  between 
different  users  of  CMS.  This  reduces  workloads  related  to 
telephone  communication  and  paperwork.  Also,  the  hard  copy 
option  provided  by  CMS  could  be  useful  in  the  generation  of  logs 
and  historical  records,  automating  such  work  currently  being 
performed  manually  by  O' Ha re  personnel. 


SOFTWARE  DESIGN  CONSIDERATIONS 


This  section  deals  with  the  discussion  of  several  design  factors 
considered  for  the  CMS  software  in  its  current  form  residing  in 
the  time  sharing  environment  of  MITRE  Washington's  Computer 
Center.  Currently,  CMS  is  housed  in  an  IBM  4341  computer  with 
VM/SP  operating  system.  CMS  employs  the  IBM's  Display 
Management  System  (DMS)  software  package  that  provides  full 
screen  menu  type  displays.  The  display  terminals  used  by  CMS 
are  IBM's  3270  series  or  equivalent. 

3.1  General  Design  Requirements 

In  order  to  interface  with  DMS  software  package  one  of  the 
following  programming  languages  was  needed:  COBOL,  RPGII,  PL/I, 
or  Assembler.  The  DMS  language  requirement,  as  well  as  the  need 
for  a  high  level  programming  language  suited  for  scientific 
applications  have  led  to  the  choice  of  PL/I  as  the  programming 
language  for  CMS.  Hence,  the  CMS  software  is  written 
exclusively  in  PL/I  and  complies  fully  with  top-down  structured 
programming  techniques. 

In  1 t 8  final  Implementation  at  O'Hare,  CMS  is  envisioned  to  have 
direct  Interfaces  with  existing  and  future  monitoring  systems 
providing  automated  inputs  that  would  greatly  reduce  the  user 
participation.  However,  in  the  absence  of  such  automated 
interfaces,  the  current  version  of  CMS  requires  manual  Inputs  b;, 
the  participants.  As  a  result,  care  has  been  taken  to  make  the 
system  as  user  friendly  as  possible  without  increasing  the 
workloads  of  its  users.  In  working  towards  these  goals,  the 
multi-terminal  (user)  concept  has  been  Introduced  in  order  to 
Increase  the  efficiency  of  input  process  by  spreading  it  among 
several  users. 

Besides  the  reduction  of  workload  resulting  from  spreading  of 
the  input  process  among  several  users,  CMS  offers  other  features 
that  make  it  a  user  friendly  system.  These  features  are  mostly 
in  the  area  of  Input/output  interfaces  to  CMS  enhancing  the  ease 
with  which  the  users  interact  with  the  system. 


One  of  these  areas  is  the  invocation  process  of  various  CMS 
functions.  For  the  purpose  of  invoking  the  various  CMS 
functions,  the  excessive  use  of  keyboard  strokes  and/or  the  need 
for  command  oriented  conversational  languages  have  been 
eliminated.  Instead,  in  order  to  initiate  each  CMS 


function,  a  separate  key  on  the  terminal  keyboard  is  used 
requiring  only  a  single  stroke.  These  keys  are  referred  to  here 
and  throughout  this  document  as  program  function  (PF)  keys.  In 
order  to  remind  the  users  of  the  definition  of  various  PF  keys, 
CMS  displays  a  list  of  all  the  PF  keys  and  their  associated 
functions  when  it  is  activated,  and  thereafter  upon  request. 
However,  in  the  final  implementation  of  CMS  the  program  function 
keys  on  the  terminal  keyboard  will  be  labeled  with  the  name  or 
description  of  the  function  they  represent. 

Another  feature  offered  by  CMS  is  in  the  area  of  the  man-machine 
interface.  In  order  to  assist  the  users  in  input/output 
processes,  CMS  provides  menu  type  input/output  screens 
(Figure  3-1)  .  These  screens  are  designed  and  formatted  so  as 
to  eliminate  extraneous  effort  on  the  part  of  the  users  by 
displaying  the  description  of  the  required  inputs  and  outputs. 
In  case  of  inputs,  CMS  screens  provide  space  to  move  the  cursor 
onto  and  type  at  most  a  single  number  or  a  symbol  to  initiate  a 
particular  input  process.  Menu  type  screens  are  particularly 
useful  since  they  are  self-explanatory,  easy  to  learn,  and 
simple  to  operate.  Additionally,  CMS  menu  type  screens  provide 
the  ability  to  display  selected  information  in  high  intensity 
for  more  emphasis. 

In  addition  to  the  above  features,  CMS  contains  error  checking 
and  data  validation  routines  for  each  screen  that  prevent  the 
user  from  accidently  entering  erroneous  data.  If  the  user  makes 
an  error  on  the  screen,  the  input  is  not  accepted  by  CMS,  and  a 
highlighted  message  instructs  him  with  corrective  measures  and 
places  the  cursor  on  the  faulty  entry.  This  capability  of  CMS 
is  helpful  in  not  only  preventing  erroneous  and  invalid  data 
entries,  but  in  serving  as  a  self-training  process  for  the 
user.  As  the  user  encounters  various  error  messages,  he  becomes 
more  familiar  with  the  system  and  learns  how  to  use  it  more 
effectively. 

3.2  Design  Limitations  of  a  Time-Share  System 

There  are  a  number  of  limitations  associated  with  the  design  of 
CMS  in  its  current  form  in  the  time  sharing  environment.  These 
limitations  will  not  exist  if  CMS  were  to  be  implemented  on  a 
stand-alone  compute.*  as  is  envisioned  for  O'Hare  in  the  future. 

The  time  sharing  environment  where  CMS  resides  does  not  allow 
multi-tasking,  and  therefore  control  and  communciation  between 
several  terminals  via  a  single  program  is  not  possible. 
Therefore,  in  order  to  implement  the  multi-terminal  concept 
associated  with  CMS,  three  separate  programs  were  prepared. 
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Each  program  Is  compiled  and  scored  separately  and  activated 
from  its  display  terminal.  The  use  of  three  programs  in  this 
fashion  introduces  additional  constraints  in  terms  of  computer 
resources  and  processing  efficiency  that  otherwise  would  not 
exist.  The  three  programs  within  the  CMS  software  package  are 
loaded  simultaneously  into  the  computer  memory  at  execution  time 
requiring  more  processing  resources  than  a  single  program.  This 
added  to  the  fact  that  in  the  time  sharing  environment  other 
jobs  are  processed  simultaneously  affects  the  CMS  response  time 
dramatically.  Additionally,  the  cost  associated  with  storing, 
maintaining,  and  modifying  the  CMS  software  package  is  increased 
considerably  as  a  result  of  having  multiple  programs  as  opposed 
to  a  single  program. 

Another  limitation  imposed  by  the  time  sharing  environment  on 
CMS  is  in  the  area  of  automatic  updating  capability.  Currently, 
CMS  can  not  provide  automatic  updating.  Updating  is  done  on 
request  since  each  program  operates  independently  and  is  not 
aware  of  the  activities  of  the  other  programs. 
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SOFTWARE  ARCHITECTURE 


4.1  Major  Subsystems 

CMS  Is  a  collection  of  three  programs  that  are  stored  and 
compiled  separately  and  operate  independently.  The  programs 
work  in  parallel  with  each  other;  each  accesses  a  central  data 
base  containing  all  information  on  O'Hare  status  over  the 
planning  horizon. 

The  programs  within  the  CMS  software  package  consist  of  a 
collection  of  screens  each  containing  a  predetermined  set  of 
information.  In  some  cases  there  is  an  overlap  of  information 
among  several  screens.  For  example,  the  current  operating 
configuration  is  indicated  on  as  many  as  four  separate  screens. 
Although  the  screens  are  not  mutually  independent  (i.e.,  changes 
in  one  screen  may  affect  the  contents  of  the  others),  they  are 
self-contained  in  that  they  serve  a  specific  purpose  and  are 
acted  upon  separately. 

Each  screen  within  a  program  is  considered  to  be  a  subsystem, 
consisting  of  routines  that  prepare  the  displayed  data,  control 
the  screen,  and  perform  error  checking  and  data  validation 
functions.  Table  4-1  contains  a  list  of  all  the  screens 
available  within  the  CMS  software  package. 

4.2  Flow  of  Control 


There  are  two  states  associated  with  each  program  while  it 
operates:  waiting  state  and  execution  state.  When  the  program 
is  in  the  waiting  state,  a  particular  screen  is  displayed.  As 
long  as  the  user  does  not  request  an  update  or  a  new  screen,  the 
program  remains  in  the  waiting  state.  However,  the  user  can 
continue  the  use  of  the  displayed  screen  by  changing,  deleting, 
or  adding  data  as  desired.  The  program  in  waiting  state 
continues  to  perform  the  error  checking  and  data  validation 
functions  local  to  the  displayed  screen.  As  long  as  the  user 
does  not  initiate  an  update  function  or  request  a  change  of 
screens,  the  displayed  data  remains  local  to  the  screen,  and  can 
be  restored  to  its  original  form  without  going  through  the  data 
base. 

If  the  update  function  is  initiated,  or  if  a  new  screen  is 
requested,  the  program  enters  the  execution  state.  Once  in  the 
execution  state,  the  central  data  base  is  accessed,  its  contents 
are  changed  by  the  new  data  obtained  from  the  displayed  screen, 
and  then  it  is  released.  After  the  release  of  the  data  base  is 
completed,  a  number  of  pertinent  calculations  are  performed  with 


TABLE  4-1 

LIST  OF  INPUT/OUTPUT  DISPLAY  SCREENS 

Menu  of  Program  Function  Keys  and  Program  Termination 
Parameters 

O'Hare  Status  Summary 
Planning  Log  Selection 
Wind  and  Weather  Planning  Log 
Runway  Conditions  Planning  Log 
Equipment  Planning  Log 
Demand  Planning  Log 

Airport  Status  (Current/Forecast) 

! .  Runway  Equipment  Status  (Current/Forecast) 

i.  Demand  Profile  (Current/Forecast) 

j.  Ordered  List  of  Configurations  (Current/Forecast) 
Current  Departure  Queues 

Ordered  List  of  Transitions 

).  Configuration  Information  (Current/Forecast) 


the  new  updated  data.  These  include:  wind  components  analysis, 
runway  minima  computations,  runway  availability  analysis, 
configuration  eligibility  analysis,  capacity  calculations,  and 
demand  balancing.  At  the  end  of  the  computations  referred  to 
above,  the  program  returns  to  waiting  state  by  displaying  the 
new  requested  screen  or  updated  previous  screen. 

4.3  Screen  Control 

CMS  employs  IBM's  Display  Management  System  (DMS)  software 
package  to  provide  the  means  for  the  user  to  communicate  with  it 
via  menu  type  display  screens.  Each  of  the  screens  within  the 
CMS  is  invoked  by  pressing  a  key  on  the  display  terminal 
keyboard  called  program  function  key  (PF  key).  There  are  twelve 
PF  keys  numbered  1  through  12  available  on  IBM's  3270  display 
terminal  keyboard  or  equivalent  currently  used  by  CMS.  Figure 
4-1  shows  the  layout  of  the  display  terminal's  keyboard  and  the 
placement  of  PF  keys. 

The  screens  are  predetermined  and  formatted  in  advance.  They 
each  contain  permanent  text  fields  that  describe  the  type  of 
information  required  on  that  screen.  Also,  each  screen  provides 
a  number  of  data  fields  where  the  user  can  input  data  or  CMS  can 
display  the  required  information.  Figure  4-2  contains  an 
example  of  a  CMS  screen  with  its  text  and  data  fields.  However, 
if  the  data  fields  are  used  for  Information  display  only,  then 
they  can  be  locked  out  so  as  to  not  permit  any  entries.  More¬ 
over,  DMS  provides  the  capability  to  display  both  the  text  and 
data  fields  in  high  intensity  to  help  emphasize  or  bring  to 
attention  certain  types  of  information  on  the  screen. 

The  loading  and  unloading  of  the  data  onto  and  from  various 
screens  are  controlled  by  DMS.  DMS  recognizes  the  data  in 
character  form  only.  Therefore,  if  a  numerical  input  is 
required  (e.g.,  ceiling),  CMS  software  contains  special  routines 
that  convert  the  data  from  numerical  to  character  form  and  vice 
versa  Internally  before  and  after  displaying  them  on  the  screen. 

Once  in  the  waiting  state,  CMS  awaits  user's  response  either  in 
the  form  of  request  for  a  new  screen  or  data  entry  on  the 
screen.  The  new  data  enteries  are  not  accepted  by  CMS  unless 
the  ENTER  key  (see  Figure  4-1)  is  pressed  and  no  error  is 
detected.  Pressing  the  ENTER  key  activates  the  screen's  error 
checking  and  data  validation  routines.  These  routines  check 
each  new  entry  individually;  if  an  erroneous  or  invalid  data  is 
detected,  a  message  of  appropriate  corrective  action  is  Issued 
and  that  entry  is  highlighted  with  the  cursor  placed  on  it.  In 
some  instances  a  new  entry  may  cause  a  number  of  changes  on 
other  data  fields  on  the  same  screen.  In  these  cases  the  local 
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The  CMS  software  package  is  a  collection  of  three  separate 
prograas  each  dedicated  to  a  different  user  within  the  O'Hare 
facility.  These  three  users  are:  the  Assistant  Chief  (AC), 
teaa  supervisor  of  the  tower  cab  (CAB),  and  the  Airway 
Facilities  operations  officer  (AF).  Since  AC  has  the  primary 
responsibility  of  configuration  selection,  his  program  provides 
a  full  access  to  all  the  available  screens.  In  contrast,  the 
other  two  prograas  have  only  a  limited  access  to  all  the 
screens.  Table  4-2  shows  each  program's  screen  availability. 


Despite  the  differences  in  the  number  of  available  screens,  all 
three  prograas  have  similar  structures.  However,  since  the  CAB 
and  AF  programs  do  not  have  access  to  screens  that  perform  a 
number  of  planning  functions  for  the  AC,  namely  ordered  list  of 
configurations  and  transitions  screens,  these  programs  do  not 
contain  the  routines  that  perform  the  computations  in  the 
execution  state  (l.e.,  wind  components,  runway  closure,  capacity 
analysis,  etc). 

Apart  from  the  major  differences  between  three  programs 
discussed  above,  there  are  some  minor  differences  associated 
mostly  with  the  individual  screens  accessed  by  more  than  one 
program.  The  planning  log  screens  (l.e.,  wind  and  weather, 
equipment,  runway  conditions)  contain  predesignated  data  entry 
areas  for  each  user.  Although  the  same  planning  log  screens  are 
accessed  by  different  users,  each  user  makes  entries  on 
different  part  of  these  screens  designated  to  him.  Also,  the  AF 
and  CAB  have  access  to  a  number  of  screens  that  are  for  display 
only  purposes,  and  are  designed  to  lock  out  any  attempted  data 
entries. 
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CMS  DATA  BASE 


All  Che  information  essential  in  describing  O'Hare  Airport  over 
the  planning  horizon  are  stored  in  a  central  data  base.  This 
data  base  is  housed  in  an  external  storage  device  (disk)  and  is 
accessed  by  each  of  the  three  programs  based  on  a  given 
protocol.  As  the  users  interact  with  CMS,  the  contents  of  this 
data  base  are  updated  and  made  available  to  them. 

5.1  Access  Mechanism 

In  order  to  access  the  central  data  base,  each  program  employs  a 
system  subroutine  COMMD  (Reference  7).  Subroutine  COMMD  causes 
a  program  Interrupt  to  issue  a  system  command.  In  this  case, 
the  system  command  issued  by  each  program  through  subroutine 
COMMD  links  the  disk  storage  housing  the  program  to  the  one 
containing  the  CMS  data  base.  Once  the  link  is  established  the 
program  can  proceed  by  reading  or  writing  data  onto  and  from  the 
data  base.  After  the  CMS  data  base  is  updated,  the  subroutine 
COMMD  is  called  again  and  a  system  command  is  issued  releasing 
the  disk  containing  the  data  base  making  it  available  for  access 
by  other  users. 

5.2  Integrity  Mechanism 


Since  all  three  programs  may  access  the  data  base  at  any  time,  a 
system  protocol  is  established  disallowing  simultaneous  access 
of  the  data  base.  If  a  program  issues  a  link  command  while  the 
data  base  is  being  accessed  by  another  program,  the  second  link 
is  not  established  and  a  return  code  is  issued.  After  receiving 
a  'not  linked'  return  code,  the  program  issues  a  wait  command 
via  COMMD  subroutine.  The  wait  command  causes  a  program 
Interrupt  with  no  action  taken  for  5  seconds  (actual  time). 
After  expiration  of  5  seconds,  the  program  attempts  another  link 
operation.  This  process  continues  until  the  program  establishes 
a  successful  link  to  the  data  base.  With  this  mechanism  the 
simultaneous  access  of  the  data  base  by  several  users  is 
prevented. 

5.3  Data  Base  Content 


The  CMS  data  base  contains  all  information  necessary  to  describe 
O'Hare  Airport  over  the  planning  horizon.  This  central  data 
file  1 8  read  and  written  sequentially  and  contains  the  following 
Information: 

-  times  when  each  screen  within  the  CMS  package  is 
written  (stored)  in  the  data  base  (character  form), 
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Midway  flag  indicator,  current  operating  configuration 
indicator,  and  current  departure  queue  lengths 
(numerical  and  character  form). 


-  arrival  and  departure  wind  thresholds  (character  and 
numerical  form), 

information  on  airport  status  screens  (current  and 
forecast)  not  including  those  calculated  by  CMS 
(character  and  numerical  form), 

-  information  on  equipment  status  screens  (current  and 
forecast) , 

equipment  planning  log  messages  (character  and 
numerical  form), 

wind  and  weather  planning  log  messages  (character  and 
numerical  form), 

runway  conditions  planning  log  messages  (character  and 
numerical  form), 

demand  planning  log  information  (character  and 
numerical  form) 

The  format  of  the  CMS  data  base  is  discussed  in  Appendix  E. 

5.4  Other  CMS  Data  Files 


There  are  a  number  of  separate  data  files  that  contain  the 
information  needed  by  CMS,  but  are  not  part  of  the  CMS  data 
base.  Since  such  information  are  of  permanent  nature,  they  are 
read  into  the  memory  prior  to  the  execution  of  CMS  programs. 
These  files  are  the  following: 

*■  File  RNWYMIN:  contains  celling  and  visibility  minima 
associated  with  each  runway  with  various  equipment 
inoperable. 

-  File  CNFGRQ:  contains  a  list  of  available 

configurations  with  their  associated  fix  assignments 
and  capacity  file  indices. 

-  File  CAPACTY:  contains  capacity  curves  used  to 

compute  configuration  capacities. 


File  TRAVEL:  contains  f ix-to-runway  nominal  travel 

times  used  in  transition  analysis. 

File  DEPEND:  contains  exclusive  dependence  matrix 

used  in  transition  analysis. 

-  File  OAGDMND:  contains  Official  Airline  Guide  demand 
profiles  used  for  demand  planning. 

The  formats  associated  with  the  above  files  are  discussed  in 
Appendix  E. 


SYSTEM  DATA  STRUCTURES  AND  TOP  LEVEL  PROCESSING 


6.1  System  Data  Structures 

The  CMS  data  structures  can  be  categorized  in  to  six  distinct 
groups.  In  this  subsection  these  groups  are  discussed.  Volume 
II  contains  a  more  detailed  description  in  the  form  of 

pseudocode  s . 

1.  Data  structures  pertaining  to  information  on  the  CMS 

permanent  data  files  (i.e.,  TRAVEL,  DEPEND,  CAPACTY,  etc.). 

2.  Data  structures  pertaining  to  information  on  the  CMS 

calculated  variables  (i.e.,  demand  balancing  information, 
configuration  capacities,  percentage  of  arrivals,  etc.). 

3.  Data  structures  pertaining  to  screen  variables:  there  are 
two  data  structures  associated  with  each  screen  that 
contain  the  information  on  that  screen  (numerical  and 
character  form) . 

4.  Data  structures  pertaining  to  current  data  base 

information:  these  data  structures  contain  the  data  read 

from  or  written  to  the  data  base. 

5.  Data  structures  pertaining  to  original  data  base 

Information:  these  data  structures  contain  a  copy  of 

current  data  base  data  structures  at  the  time  they  are  read 
in;  used  when  the  data  base  is  being  updated  to  determine 
what  changes  have  occurred  since  the  last  update. 

6.  PF  key  variables:  associated  with  each  PF  key  there  is  a 
variable  identified  by  DMS  and  used  to  invoke  various 
screens. 

6.2  Top  Level  Processing 

The  logic  of  the  CMS  top  level  processing  given  in  this  section 
is  that  of  the  AC  program,  since  it  contair-  complete  collection 
of  the  available  CMS  screens  and  performs  ^11  the  functions  of 
CMS.  Figure  6-1  shows  the  high  level  flow  of  control  of  the  AC 
program. 

The  following  logic  is  used  by  the  AC  program: 


initialization  that  Includes  reading  of  the  permanent 

CMS  data  files  and  assigning  appropriate  values  to  the 
permanent  CMS  data  structures. 


entering  the  waiting  state  by  displaying  the  menu 
screen  and  awaiting  the  user's  response. 

interpreting  the  user's  request  for  new  screen, 
termination,  or  update. 

entering  the  execution  state. 

choosing  a  new  screen  or  function. 

reading  the  current  version  of  data  base  and  setting 
the  original,  current,  and  screen  data  structures. 

merging  different  versions  of  the  data  base  to  obtain 
the  most  recent  one. 

writing  the  most  recent  version  back,  onto  data  base, 
releasing  the  data  base. 

performing  a  number  of  analyses  and  preparing  the 
calculated  variables  of  CMS. 

displaying  the  new  requested  screen  (waiting  state). 

CMS  makes  use  of  three  different  versions  of  the  data  base:  the 
original  version  saved  at  the  time  when  the  data  base  is 
accessed,  the  current  version  which  reflects  any  changes  made  by 
the  user,  and  the  central  data  base,  which  is  the  latest 
version,  accessed  at  the  time  of  update  and  which  may  contain 
changes  made  by  other  users. 

In  order  to  merge  different  versions  of  CMS  data  base  contents 
to  obtain  the  most  recent  one,  the  following  rule  is  followed: 
if  the  current  data  base  information  is  not  the  same  as  the 
original  copy  of  the  data  base  saved  at  the  time  of  last  update, 
then  the  information  obtained  from  the  last  screen  is  the  most 
recent  version,  otherwise  the  central  data  base  information  is 
used.  Additionally,  for  computing  the  calculated  variables  of 
CMS  the  following  analyses  is  performed: 

Compute  visibility  and  ceiling  minima  based  on 
equipment  status. 

Compute  crosswind  and  tailwind  components  of  the  wind. 


Determine  runway  closures. 


Compute  north  and  south  demands  based  on  Fix-to-Runway 
assignments. 

Compute  capacity  and  saturation  (demand  balancing)  for 
each  configuration. 

Update  departure  runways  for  current  configuration. 


* 


CMS  SCREENS 


In  this  section  each  screen  within  the  CMS  software  package  is 
defined  and  the  logic  associated  with  its  operation,  error 
checking,  and  data  validation  routines  are  given  in  form  of  high 
and  low  level  pseudocodes. 

7.1  Menu  and  Parameter  Screens 


The  menu  display  screen  is  designed  to  serve  two  purposes. 
First,  it  displays  a  list  of  all  the  available  screens  and 
functions  and  their  associated  program  function  keys  -  analogous 
to  a  book's  table  of  contents  -  to  help  the  user  in  remembering 
how  to  access  a  particular  screen  or  initiate  a  specific 
function.  Second,  it  is  used  for  program  termination.  Figure 
7-1  shows  a  sample  of  menu  screen  for  the  AC  program. 

The  parameter  screen  is  designed  to  allow  the  AC  to  set  the 
airport's  arrival  and  departure  crosswind  and  tailwind 
thresholds.  These  thresholds  are  used  by  the  AC  program  to 
determine  when  a  runway  becomes  Ineligible  due  to  excessive 
wind.  Figure  7-2  contains  a  sample  of  parameters  screen. 

7.2  O'Hare  Status  Summary  Screen 

The  purpose  of  the  O'Hare  status  summary  display  screen  is  to 
provide  the  AC  with  an  overview  of  the  current  operating 
conditions  of  the  airport.  For  this  purpose,  the  prevailing 
wind  and  weather  conditions,  as  well  as  the  current  operating 
configuration  and  its  capacity  are  displayed.  Also  shown  is  the 
relationship  of  the  capacity  for  the  current  runway 
configuration  to  the  maximum  capacity  achievable  for  current 
conditions. 

In  addition  to  the  above  summary  information,  the  bottom  half  of 
the  O'Hare  status  screen  contains  a  number  of  messages  from  the 
wind/weather,  airport,  and  equipment  planning  logs.  These 
messages  serve  as  a  reminder  to  the  AC  of  what  changes  are 
expected,  or  recently  have  been  made.  Figure  7-3  shows  a  sample 
of  O'Hare  status  summary  screen. 

7.3  Planning  Log  Screens 

In  order  to  facilitate  the  communication  among  the  three  users 
of  CMS,  a  system  of  interconnected  planning  log  screens  are 
provided.  These  screens  do  not  affect  any  of  the  status  screens 
within  the  CMS  system.  Each  user  of  CMS  has  access  to  all  or  a 
number  of  the  planning  log  screens,  utilizing  them  to 
communicate  with  the  other  users  about  the  upcoming  changes  that 
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FIGURE  7-1 

MENU  OF  PF  KEYS  FOR  AC 


PARAMETERS 
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The  purpose  of  the  planning  log  selection  screen  is  to 
consolidate  the  accessing  methods  of  the  planning  logs  that  are 
provided  for  the  AC  program.  Figure  7-4  contains  a  sample  of 
planning  log  selection  screen.  The  planning  logs  accessed  via 
this  screen  are: 


weather  and  wind  planning  log 
airport  conditions  planning  log 
equipment  planning  log 
demand  planning  log 


7.3.2  Weather  and  Wind  Planning  Log  Screen 

The  purpose  of  the  weather  and  wind  planning  log  screen  is  to 
serve  as  a  communication  tool  for  both  the  AC  and  team 
supervisor  of  the  tower  cab  (CAB)  in  relaying  information  about 
the  expected  changes  in  the  airport's  weather  and  wind 
conditions.  Usually,  such  information  is  entered  into  CMS  by 
the  CAB  position,  and  then  is  used  by  the  AC;  however,  the  AC 
can  enter  appropriate  messages  in  the  lower  half  of  the  screen 
designated  for  him/her. 

Figure  7-5  shows  a  sample  of  weather  and  wind  planning  log 
screen.  The  types  of  information  entered  on  this  display  screen 
Include  the  time,  ceiling,  visibility,  wind  direction,  and 
velocity.  Additionally,  a  remark  field  is  provided  for  any  free 
formatted  comments  that  the  user  may  deem  necessary  to  include. 

7.3.3  Airport  Runway  Conditions  Planning  Log  Screen 


The  purpose  of  the  airport  runway  conditions  planning  log  screen 
is  to  serve  as  a  communication  tool  for  both  the  AC  and  CAB  in 
relaying  Information  about  the  runway  surface  and  braking 
conditions,  and  runway  closures.  Usually,  such  information  is 
entered  into  CMS  by  the  CAB  position,  and  then  is  displayed  by 
the  AC;  however,  the  AC  can  enter  appropriate  messages  in  the 
lower  half  of  the  screen  designated  for  him. 

Figure  7-6  contains  a  sample  of  airport  runway  conditions 
screen.  The  types  of  information  entered  on  this  display  screen 
include  time,  runway  ID,  surface  and/or  braking  conditions,  and 
runway  opening/closures.  Additionally,  a  remark  field  is 
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FIGURE  7-5 

AIRPORT  PLANNING  LOG  FOR  AC 
WEATHER  AND  WIND  FORECASTS) 


AIRPORT  PLANNING  LOG 


FIGURE  7-6 

AIRPORT  PLANNING  LOG  FOR  AC 
(RUNWAY  CONDITIONS) 


provided  for  any  free  formacted  comments  that  the 
necessary  to  include. 

7.3.4  Equipment  Planning  Log  Screen 


user  may  deem 


The  purpose  of  equipment  planning  log  screen  is  to  serve  as  a 
communication  tool  among  the  AC,  AF,  and  CAB  positions  in 
relaying  information  about  the  various  equipment  outages  on 
different  runways  at  the  airport.  Usually,  such  information  is 
entered  into  CMS  by  the  AF  position,  and  then  is  displayed  by 
the  AC  and  CAB;  however,  the  AC  can  enter  approprite  messages  in 
the  lower  half  of  the  screen  designated  for  him. 

Figure  7-7  shows  a  sample  of  equipment  planning  log  screen.  The 
types  of  information  on  this  display  screen  include  the  runway 
ID,  type  of  equipment,  time  the  outage  has  occurred  or  is 
expected,  and  the  time  that  that  piece  of  equipment  is  expected 
to  return  to  service.  Additionally,  a  remark  field  is  provided 
for  any  free  formatted  comments  that  the  user  may  deem  necessary 
to  Include. 

7.3.5  Demand  Plannine  Los  Screen 


In  order  for  the  AC  to  use  CMS  as  a  planning  tool  in  selecting 
new  configurations,  detailed  information  about  the  traffic 
demand  at  O'Hare  airport  is  needed.  The  demand  planning  log 
screen  is  designed  to  display  a  set  of  predetermined  demand 
numbers  that  are  based  on  the  Official  Airline  Guide  (OAG),  and 
historical  data  for  AC's  use.  The  AC  has  the  option  to  change 
any  of  the  displayed  data  depending  on  the  airport's  current 
traffic  profile.  This  screen  contains  hourly  accounts  of  the 
total  number  of  arrivals  and  departures  based  on  the  OAG  that 
are  expected  at  O'Hare,  and  their  respective  fix  distributions. 
Figure  7-8  contains  a  sample  of  demand  planning  log  screen. 

7.4  Airport  Status  Screens 


There  are  two  screens  associated  with  the  airport  status: 
current  and  forecast.  The  purpose  of  these  two  screens  (current 
and  forecast)  is  to  serve  both  as  communication  and  planning 
tools  for  the  AC.  The  current  airport  status  screen  provides 
the  AC  with  the  latest  airport  information  entered  and  updated 
by  the  CAB  position,  as  well  as  computed  by  CMS.  The  AC  is  also 
permitted  to  change  or  modify  any  of  that  information.  In 
contrast,  the  forecast  airport  status  screen  is  used  only  by  the 
AC  for  planning  purposes.  The  AC  can  enter  the  forecast  airport 
condition  on  this  screen,  and  later  use  them  to  determine  the 
favorableness  of  different  configurations  in  terms  of  transition 
and  capacity  impacts. 
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FIGURE  7-8 
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indication  of  Midway  airport’s  use  of  runway  13R  under 
1FR  conditions 

tower  imposed  runway  closures 

-  runway  RVR  reading 
Information  provided  by  CMS  (computed) 

runway  wind  conditions 

-  runway  crosswind  and  tailwind  components 
runway  minima  for  ceiling  and  visibility 

-  summary  of  runway  closures  due  to  all  possible  causes. 
7.5  Equipment  Status  Screens 

There  are  two  screens  associated  with  the  equipment  status: 
current  and  forecast.  The  purpose  of  these  two  screens  (current 
and  forecast)  is  to  serve  both  as  communication  and  planning 
tools  for  the  AC.  The  current  runway  equipment  status  screen 
provides  the  AC  with  the  latest  status  of  the  equipment  on 
various  runways  as  entered  and  updated  by  the  AF  position.  The 
AC  is  also  permitted  to  change  or  modify  that  Information.  In 
contrast,  the  forecast  runway  equipment  status  screen  ;is  used 
only  by  the  AC  for  the  planning  purposes.  The  AC  can  enter  the 
forecast  runway  equipment  status  on  this  screen,  and  later  use 
it  to  determine  the  favorableness  of  different  configurations  in 
terms  of  capacity  and  transition  impacts. 

Figure  7-10  contMns  a  sample  of  equipment  status  screen.  The 
following  runway  equipment  is  listed  on  this  screen: 

CAT  II 

-  Localizer  (LOC) 

Clide  Slope  (GS) 

Outer  Marker  (0M) 
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Inner  Marker  (IM) 

Middle  Marker  (MM) 

Runway  Alignment  Indicator  Lights  (RAIL) 

Approach  Lighting  System  (ALS) 

High  Intensity  Runway  Lights  (HIRL) 

Runway  Visual  Range  (RVR) 

Centerline  Lights  (CL) 

Touch  Down  Zone  (TDZ) 

-  Non-Directional  Beacon/VHF  Omni-Directional  Range 
(NDB/VOR) 

7.6  Demand  Profile  Screens 

There  are  two  screens  associated  with  the  demand  profile: 
current  and  forecast.  The  purpose  of  these  two  screens  (current 
and  forecast)  is  to  serve  as  planning  tools  for  the  AC.  In 
order  for  CMS  to  compute  capacities  of  different  configurations 
and  analyze  the  transitions,  the  total  hourly  traffic  demand  and 
its  distribution  at  the  fixes  for  both  the  arrivals  and 
departures  are  needed.  The  demand  profile  display  screens  are 
designed  to  provide  such  information  to  CMS.  Figure  7-11  shows 
a  sample  of  demand  profile  screen. 

7.7  Ordered  List  of  Configurations  Screens 

The  purpose  of  these  two  screens  (current  and  forecast)  is  to 
serve  as  planning  tools  for  the  AC.  The  current  and  forecast 
ordered  list  of  configurations  display  screens  provide  the  AC 
with  a  list  of  all  the  eligible  configurations  ranked  by  their 
respective  capacities  under  specified  airport,  equipment,  and 
demand  conditions.  The  AC  can  then  use  this  information  for 
selecting  the  next  best  configuration.  Both  screens  are 
identical  in  format;  each  contains  the  airport's  percentage  of 
arrivals  and  number  of  eligible  configurations  for  its 
corresponding  environment,  Additionally,  each  screen  provides  a 
list  of  configurations  with  their  respective  capacities.  Figure 
7-12  shows  a  sample  of  ordered  list  of  configurations  screen. 

7.8  Current  Departure  Queue  Screen 


Since  the  departure  queues  at  O'Hare  have  a  substantial  impact 
on  configuration  changes,  CMS  requires  them  for  its  transition 
analysis.  Every  time  the  AC  wishes  to  use  CMS  to  assess  the 
favorableness  of  various  transitions,  the  length  of  departure 
queues  (number  of  aircraft)  for  current  departure  runways  need 
to  be  supplied.  Figure  7-13  contains  a  sample  of  departure 
queue  length  screen. 


CURRENT  DEMAND  (FROM  2534  TO  1634) 


«  «  « 
« 

« 

* 

« 

« 

« 

« 

« 

* 


««««««««««««««««««««««« 


•  • 

U 

06 

►J 

<r 

CM 

CM  V0 

a 

CM 

CM  O 

CM  00 

< 

v£> 

H 

CM 

H 

1^. 

■H  CM 

CM  .-l 

• 

> 

• 

M 

•< 

• 

06 

a. 

w 

06 

• 

• 

• 

•  • 

w 

• 

•  • 

•  • 

> 

< 

• 

• 

• 

•  • 

Q 

• 

•  • 

•  • 

u 

• 

• 

• 

•  • 

• 

•  • 

•  • 

M 

cn 

• 

CO  X 

a  • 

SC  • 

06 

< 

« 

• 

X  X 

< 

H  H 

H  H 

H 

H 

00  H 

W  Brf 

H 

a  co 

S3  C/5 

W 

O 

3  O 

•<  < 

O 

o  < 

O  W 

e6 

H 

06  O 

>  fc. 

H 

x  w 

C/5  ^ 

«  «  « 
« 
« 
« 
« 
« 
« 
* 
« 
« 
« 
« 
« 
* 
« 
* 
« 
« 
* 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 
« 

« 

« 

* 

« 

« 

« 

« 

« 

« 

« 

« 

« 

* 

« 

« 

« 

« 

« 

« 

« 

« 

« 

■K 

« 

« 

« 

* 

« 

« 

* 

* 

* 

* 

* 


FIGURE  7-11 

CURRENT  DEMAND  FOR  AC 
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7.9  Ordered  List  of  Transitions  Screen 


The  purpose  of  this  screen  is  to  serve  a^  a*  planning  tool  for 
the  AC.  The  ordered  list  of  transitions  display  screen  provides 
the  AC  with  a  list  of  all  the  possible  transitions  ranked  based 
on  their  respective  transition  hour  capacities.  The  AC  can  then 
use  this  information  in  selecting  the  next  configuration.  This 
screen  contains  the  airport's  forecast  percentage  of  arrivals 
and  number  of  eligible  configurations.  Additionally,  the  screen 
contains  the  airport's  current  operating  configuration  and  a 
list  of  configurations  eligible  for  transition.  Also,  for  each 
such  configuration,  a  theoretical  transition  duration,  a 
transition  hour  capacity,  and  a  final  steady  state  capacity  are 
given.  Figure  7-14  contains  a  sample  of  ordered  list  of 
transitions  screen. 

7.10  Configuration  Information  Screens 

There  are  two  screens  associated  with  the  configuration 
information:  current  and  forecast.  The  purpose  of  these  two 

screens  (current  and  forecast)  is  to  serve  as  planning  tools  for 
the  AC.  If  the  AC  wishes  to  acquire  detailed  Information  on  the 
performance  of  any  eligible  configuration  under  current  or 
forecast  conditions,  he  can  use  these  screens. 

Figure  7-15  contains  a  sample  of  configuration  information 
screen.  These  screens  contain  the  following  information  for  the 
north  complex,  south  complex,  and  entire  airport: 

1.  percentage  of  arrivals 

2.  saturation  levels 

3.  arrival  and  departure  demands 

4.  arrival  and  departure  capacities. 

Also,  included  in  these  screens  is  an  area  where  a  new 
configuration  can  be  entered,  if  the  AC  wishes  to  review  its 
detailed  information. 
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INTERCONNECTIVITY  OF  SCREENS 


In  this  section  the  relationships  betwen  various  screens  within 
the  CMS  software  package  are  discussed.  Although  each  CMS 
screen  is  designed  to  serve  a  specific  purpose,  they  are  not 
mutually  exclusive  (i.e.,  there  may  be  an  overlap  of  information 
between  two  or  more  screens).  There  are  two  types  of 
relationships  that  may  exist  between  two  or  more  screens: 
implicit  and  explicit. 

Although  two  or  more  screens  may  not  have  an  overlap  of  data, 
changes  in  one  screen  might  directly  affect  other  screens.  This 
type  of  connectivity  between  screens  is  defined  as  implicit 
connectivity.  For  example,  a  change  in  the  values  of  tailwind 
and  crosswind  thresholds  on  parameter  screen  may  affect  the 
results  of  runway  availability  analysis  on  airport  status  screen. 

On  the  other  hand,  the  explicit  relationship  among  CMS  screens 
is  defined  as  simply  the  overlap  of  the  same  information  between 
two  or  more  screens.  For  example,  the  prevailing  ceiling  is 
reflected  on  O'Hare  status  screen  as  well  as  current  airport 
status  screen.  Figure  8-1  and  Table  8-1  depict  the  implicit  and 
explicit  connectivity  between  various  CMS  screens. 


FIGURE  8-1 

IMPLICIT  CONNECTIVITY  OF  CMS  SCREENS 


TABLE  8-1 

EXPLICIT  CONNECTIVITY  OF  CMS  SCREENS 


APPENDIX  A 


CMS  SOFTWARE  LOGIC  -  HIGH  LEVEL  PSEUDOCODES 


This  appendix  presents  the  CMS  software  in  the  form  of  high  level 
pseudocodes  that  describe  the  purpose  and  logic  of  each  CMS  routine, 
irrespective  of  its  variable  specifications. 

A  more  detailed  description  of  the  CMS  software  logic  is  given  in 
Volume  II  (low  level  pseudocodes).  Additionally,  a  cross-reference 
table  (Table  A-l),  where  the  CMS  software  routines  are  listed 
alphabetically  with  their  locations  within  Appendix  A  and  Volume  II, 
is  given  The  high  level  pseudocodes  are  divided  into  the  following 
modules ; 

1.  High  level  processing  (pages  A-6  to  A-48) 

I .  O'Hare  status  summary  screen  (pages  A-49  to  A-59) 

3.  Planning  log  selection  screen  (pages  A-60  to  A-65) 

4.  Weather  and  wind  planning  log  screen  (pages  A-66  to  A-76) 

5.  Airport  runway  surface  planning  log  screen  (pages  A-77  to 
A-88) 

6.  Equipment  planning  log  screen  (pages  A-89  to  A-101) 

7.  Demand  planning  log  screen  (pages  A-102  to  A-lll 

8.  Airport  status  screen  (pages  A-112  to  A-l 19) 

9.  Runway  equipment  status  screen  (pages  A-120  to  A-124) 

10.  Demand  profile  screen  (pages  A-125  to  A-135) 

II.  Ordered  list  of  configurations  screen  (pages  A-136  to  A-144) 

12.  Departure  queue  screen  (pages  A-145  to  A-150) 

13.  Ordered  list  of  transitions  screen  (pages  A-151  to  A-164) 

14.  Configuration  information  screen  (pages  A-165  to  A-174) 

15.  Menu  and  parameter  screens  (pages  A-175  to  A-180) 


TABLE  A-l 


CROSS 


Routine 


ACHECK 

ADJST 

AGLOBAL 

ARPT 

ASCREEN 

ASSIGN 

AUPDATE 

AVALID 

CALC 

CAPCAL 

CAPSAT 

C CHECK 

CGLOBAL 

CHOOSE 

CLOSING 

CNFG 

CONSET 

CSCREEN 

CUPDATE 

CVALID 

DBAL 

DC HECK 

DEMSET 

DGLOBAL 

DMND 

DSCREEN 

DUR 

DVALID 

ECHECK 

EDP 

EGLOBAL 

ELIG 

ELOG 

ESCREEN 

EUPDATE 

EVALID 

FILES 

G CHECK 

GETFILE 

GGLOBAL 


REFERENCE  OF  HIGH  LEVEL  AND  LOW  LEVEL  PSEUDOCODES 
FOR  APPENDIX  A  AND  VOLUME  II 


High  Level  Low  Level 

(Appendix  A)  (Volume  II) 


A-116 

2-272 

A-l  6  2 

2-389 

A-21 

2-82 

A-l  12 

2-267 

A-l  13 

2-268 

A-20 

2-79 

A-l  18 

2-278 

A-l  18 

2-276 

A-l  60 

2-371 

A-45 

2-131 

A-39 

2-120 

A-l  7  3 

2-417 

A-23 

2-91 

A-ll 

2-66 

A-30 

2-96 

A-165 

2-401 

A-158 

2-361 

A-166 

2-402 

A-l  7  3 

2-420 

A-l  7  3 

2-419 

A-46 

2-133 

A-l  2  9 

2-298 

A-158 

2-362 

A-22 

2-87 

A-l  2  5 

2-293 

A-l  2  6 

2-294 

A-162 

2-385 

A-133 

2-306 

A-93 

2-233 

A-l  6  3 

2-391 

A-23 

2-86 

A-31 

2-104 

A-89 

2-229 

A-90 

2-230 

A-100 

2-244 

A-95 

2-237 

A-36 

2-115 

A-105 

2-252 

A- 7 

2-61 

A-25 

2-95 

TABLE  A-l 
(Continued) 


Routine 


High  Level 


Low  Level 


GSCREEN 

A- 

103 

2-249 

GVALID 

A- 

110 

2-260 

HCHECK 

A- 

58 

2-176 

HSCREEN 

A- 

54 

2-166 

HSTAT 

A- 

49 

2-152 

INREAD 

A- 

9 

2-63 

LCHECK 

A- 

63 

2-183 

LOGS  A- 

60 

2-179 

LSCREEN 

A- 

60 

2-180 

LUPPATE 

A- 

64 

2-185 

LVAL1D 

A- 

64 

2-174 

MENUPRM 

A- 

175 

2-424 

MERGE 

A- 

16 

2-73 

MILES  A- 

8 

2-61 

MINIMA 

A- 

26 

2-99 

MSCREEN 

A- 

176 

2-426 

OBJFUN 

A- 

163 

2-396 

OCHECK 

A- 

143 

2-328 

ORDER 

A- 

136 

2-313 

OSCREEN 

A- 

140 

2-321 

OSETUP 

A- 

137 

2-315 

OSORT  A- 

139 

2-319 

OUPDATE 

A- 

143 

2-331 

OVALID 

A- 

143 

2-330 

PCHECK 

A- 

180 

2-430 

PERCENT 

A- 

37 

2-116 

PGLOBAL 

A- 

24 

2-91 

PSCREEN 

A- 

177 

2-427 

PVALID 

A- 

180 

2-432 

Q CHECK  A- 

149 

2-338 

QFIX  A- 

38 

2-119 

QGLOBAL 

A- 

24 

2-93 

QSCREEN 

A- 

146 

2-335 

QUEUE  A- 

145 

2-334 

QVALID  A- 

149 

2-339 

RCHECK 

A- 

123 

2-285 

READER 

A- 

14 

2-71 

RGLOBAL 

A- 

22 

2-84 

RHO  A- 

47 

2-146 

RSCREEN 

A- 

121 

2-282 

RUPDATE 

A- 

123 

2-288 

RWY  A- 

120 

2-281 

TABLE  A-l 
(Concluded) 


Routine 

High  Level 

Low  Li 

SCHECK 

A-81 

2-213 

SGLOBAL 

A-25 

2-94 

SLOG 

A-77 

2-209 

SPTRAN 

A-l  5  9 

2-366 

SSCREEN 

A-78 

2-209 

SUPDATE 

A-87 

2-225 

SVALID 

A-83 

2-217 

TCHECK 

A-l  5  4 

2-349 

TDEP 

A-159 

2-364 

TODTACH 

A-l  4 

2-71 

TOLINK 

A-14 

2-70 

TRAN 

A-l  5  5 

2-350 

TSCREEN 

A-l  5  2 

2-343 

TSETUP 

A-151 

2-342 

UPDATE 

A- 21 

2-80 

WCHECK 

A-69 

2-192 

WGLOBAL 

A-25 

2-93 

WIND 

A-30 

2-97 

WLOG 

A-66 

2-188 

WRITER 

A-l  5 

2-72 

WSCREEN 

A-67 

2-189 

WUPDATE 

A-75 

2-205 

WVALID 

A-72 

2-197 

FIGURE  A-1 

SCHEMATIC  DIAGRAM  OF 
TOP  LEVEL  PROCESSING  ROUTINES 


PERFORM  READ  DATA  BASE;  (read  all  variable  I  froa  data  base] 


ELSEIF  previous  prograa  status  Is  set  to  deaand  planning  log  screen  (PF16)  AND 
deaand  planning  log  screen  aessage  is  not  equal  to  'DATA  STORED' 
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ELSEIF  previous  prograa  status  Is  set  to  ordered  list  of 

configurations  (PP6)  AMD  ordered  list  of  configurations 
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THEM  update  tine  on  STORED  variable  pertaining  to 
ordered  list  of  transitions  screen; 


ROUTINE  UPDATE 

nfas  routine  performs  a  number  of  Inner  model  computations  needed  during  each  update  cycle  i 
weather  minima,  crosswind  and  tailwind  components  of  wind,  runway  closures,  and  configuration 

SllolKiMfu  at>K  1  ° 


END  AGLOBAL; 


ROUTINE  QCLOBAL 

(This  routine  reconciles  different  versions  of  current  departure  queue  infornation] 


Set  runway  ceiling  aininun  equal  to  aaxiaua  of  runway  ceiling 
ainlaua  and  runway  ceiling  niniaun  with  NDB_VOg  operable  and 
localizer  and  BAIL  inoperable; 


Convert  runway  celling  and  visibility  nlnina  to  character 


lB  operable  AKD  SUde  slope  Is  operable 


END  MINIMA; 


ENDREPEAT 
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NL 


VM 


RUNWAY  CLOSURE  ELIGIBILITY  CHECK 


END  HOLD  SHORT  ELIGIBILITY  CHECK; 


EjjPgEPEAT 


PROCESS  CAPACITY_CUKVE_SELECTION 

(This  process  'selects  proper  cepsclty  curve  for  north  and  south  complexes] 


SOUTH  COMPLEX  CAPACITY  CALCULATIONS 


-7  S 


HSCREEN 


HCHECK 


P 


FIGURE  A-2 

SCHEMATIC  DIAGRAM  OF 
O’HARE  STATUS  SCREEN  ROUTINES 


A-48 
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AIRPORT  PUNNING  LOG  MESSAGE  GENERATION 


LSCREEN 

LCHECK 


LVALID 


LUPDATE 


ENDREPEAT 


WLOG 


FIGURE  A-4 

SCHEMATIC  DIAGRAM  OF 

WEATHER  AND  WIND  PLANNING  LOG  SCREEN  ROUTINES 
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EXIT! F  error  Is  detected 


END  VEL  DATA  FIELD  ERROR  CHECK: 


screen  message  Is  equal  to  'DATA  ENTERED' 


T 


L" 


[This  routine  perform*  data  validation  checks  on  screen  entrlei 
and  returns  value  for  cursor  pointing  to  first  invalid  data 
field.  Also,  an  appropriate  screen  message  is  issued  advising 
user  with  corrections] 


END  LEFT  JUSTIFY  BEAK  DATA  ENTRY; 


THEN  highlight  erroneous  entry; 


Increment  cursor 


PERFORM  LEFT  ZERO  PADDING  ON  RTS 


PROCESS  RIGHT_JUSTIFY_RWY_DATA_ENTRY 

[This  process  right-Justifles  runway  ID  entry] 


LEFT  ZERO  PADDING  ON  RTS  TIME  ENTRY 


GVALID 


FIGURE  A-7 

SCHEMATIC  DIAGRAM  OF 
DEMAND  PLANNING  LOG  SCREEN  ROUTINES 


ROUTINE  G SCREEN 

[This  routine  control*  deaand  planning  log  screen] 


CGT  DATA  FIELD  ERROR  CHECK; 
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FIGURE  A-8 

SCHEMATIC  DIAGRAM  OF 
AIRPORT  STATUS  SCREEN  ROUTINES 
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A—  111 
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(This  routine  perforce  data  validation  checks  on  screen  entries  and 
returns  value  for  cursor  pointing  to  first  invalid  data  field.  Also,  an 
appropriate  screen  nessage  is  Issued  advising  user  with  corrections) 


ENDREPEAT 


[This  routine  closes  runways  based  on  wind  dlrec 


FIGURE  A-9 

SCHEMATIC  DIAGRAM  OF 
EQUIPMENT  STATUS  SCREEN  ROUTINES 


ROUTINE  RSCREEN 

(This  routine  controls  runway  equipment  status  screen] 


ENDREPEAT 


DVALID 


FIGURE  A-10 

SCHEMATIC  DIAGRAM  OF 
DEMAND  PROFILE  SCREEN  ROUTINES 


A- 127 
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MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  Of  STANDARDS -1963 -A 


[This  routine  checks  for  errors  occurred  on  screen  ss  a  result  of  an  erroneous  entry  and 
returns  value  for  cursor  pointing  to  first  data  field  where  an  error  haa  occurred;  and  an 
appropriate  screen  nessage  la  issued  advising  user  with  correctional 


AM  FAUM  DATA  FIELD  ERROR  CHECK] 


[This  routine  performs  data  validation  checks  on  screen  entries  and 
returns  value  for  cursor  pointing  to  first  Invalid  data  field.  Also,  an 
appropriate  screen  message  Is  Issued  advising  user  with  corrections] 


SCROLL 


highlight  erroneous  entry; 


TSETUP 


[Thia  routine  computes  deaand  values  for  eael 
pertaining  to  current  configuration] 


routine  prepares  dependence  natrli] 


itlna  coaputts  dipwdwct  aatrlx  for  two  configurations  Involved  In  transition  fron  dapandanca 


transition; 


Sec  text  aasks  and  data  Basks  to  normal  Intensity 


PROCESS  INITIALIZATION 

[This  process  per  fores  a  mmber  of  necessary  initialisations  for  CSCREEN  routine  1 


L»  J""  «  IS 


it  r 


ROUTINE  P  SCREEN 

(This  routine  control* 


appropriate  screen  message  1*  Issued  advising  user  with  corrections] 


APPENDIX  B 


SYNTAX  OF  E  PSEUDOCODE* 


This  appendix  provides  a  concise  overview  of  the  syntax  of  the 
pseudolanguage  EL  The  information  supplied  should  be  sufficient  to 
allow  the  reader  to  decipher  the  logic  specified  in  this  document. 
For  a  complete  discussion  of  pseudolanguage  in  general  and  E  in 
particular,  see  Reference  5. 

B.l  GENERAL  INFORMATION 

A.  E  ”  Eclectic  System  Specification  Language 

B.  E^  is  similar  to  other  pseudolanguages,  except  that  indentation 
counts:  no  BEGIN/END,  IF/ENDIF,  DO/OD,  etc. 

C.  Il  character  set  conventions: 

Underscored  text  denotes  E  constructs. 

Uppercase  text  denotes  "real"  program  statements. 

Lowercase  text  denotes  abstract  (pseudo)  statements. 

Brackets  ("[",  denote  comments. 

Semicolons  are  used  as  statement  delimiters. 

An  example: 


REPEAT  UNTIL  (all  conditions  satisfied); 
Obtain  message  type; 

IF  (obsolete  message  0R_  A  EQ  SQRT(B)) 
THEN  PERFORM  message_elimination; 

ENDREPEAT ; 


D.  Identifiers  have  no  inherent  length  limit.  Underscores  are  used 
to  break  up  long  names,  as  shown  in  the  example  above. 


Source:  Reference  4. 


B.2  BLOCKS 


External  Blocks 


TASKs  and  ROUTINES  are  the  external  blocks  supported  by  E.  Although 
they  are  functionally  equivalent,  ROUTINES  tend  to  be  subordinate  to 
(i.e.,  invoked  by)  TASKs. 

Syntax: 


i 

I 

1 

l 

i 

I 


TASK  tasknatae 

[IN  (input  parameter(s))] 

[OUT  (output  parameter(s) ) J 
[INPUT  (modified  parameters ) )  ] ; 


END  taskname; 


ROUTINE  routinename 

[IN  (input  parameter(s))] 

[OUT  (output  parameter(s))] 
[INPUT  (modified  parameter(s) ) ] ; 


END  routinename; 


4 


Input  parameters  are  read  by  not  modified;  output  parameters  are  set 
by  the  block;  modified  parameters  are  read  and  then  modified. 

Functions  may  also  be  defined.  The  returned  value  may  be  assigned 
to  the  single  output  parameter  or,  alternatively,  assigned  to  the 
function  name  itself. 


B-2 


FUNCTION  functionname 

[IN  (input  parameter(s) ) ] 
[OUT  (output  parameter)]; 

END  functionname; 


Invocation  of  External  Blocks 
TASKS  and  ROUTINES: 


CALL  blockname 

[IN  (input  parameter(s))] 

[OUT  (output  parameter(s) )] 
[INPUT  (modified  parameter(s))] ; 


Functions  are  invoked  by  name 


J  =>  SQRT(K) ; 

L  =*  OWNERJOF(M) 


Internal  Blocks 

Internal  blocks  (known  as  processes)  serve  as  a  means  of  decomposing 
a  large  block  (external  or  internal)  into  manageable  segments.  They 
are  known  only  to  the  block  in  which  they  are  defined.  They  do  not 
accept  parameters,  as  it  is  assumed  that  internal  blocks  have  access 
to  all  variables  known  to  the  invoking  block. 


B.3  DATA  TYPES 


Variables 


Variables  are  declared  at  the  beginning  of  a  block  in  the  form-r 
shown  below: 


BIT  bitname; 

BITS  stringname; 
CHR  stringname; 
FLG  bitname; 

FLT  name; 

INT  name; 

PTR  name; 


single  logical  bit 
bit  string 
character  string 
synonym  for  BIT 
floating  point  number 
integer 
pointer 


The  precision  of  numeric  variables  and  the  length  of  strings  are 
implementation-dependent,  although  comments  on  the  declaration  may 
be  used  to  indicate  specific  requirements. 

Arrays  are  declared  by  means  of  subscripts: 


INT  ZONES (4); 


four-element  array 


Constants 


Constants  in  £  are  variables  that  are  assigned  a  value  when  they  are 
declared  and  keep  that  value  forever.  By  convention,  constant  names 
are  preceded  by  dollar  signs  in  £  to  remind  the  reader  that  they  are 
special. 


FLT  iFTPERNM  =*  6076.115; 

INT  $TL  -  2;  Turn  Left 


On  occasion,  the  constant  is  shown  without  a  corresponding  value. 
This  convention  indicates  that  a  constant  is  required  but  that  its 
value  may  be  anything  the  system  implementor  chooses. 


Built-in  Constants 


Strictly  speaking,  the  only  hard  constants  permitted  in  code  are 
zero  and  one.  E_  recognizes  the  logical  constants  $TRUE  and  $FALSE. 
Two  special  statements  are  provided  to  set  and  clear  bits: 


SET  bltname;  bitname  »  $TRUE 

CLEAR  bitname;  bitname  *  $FALSE 


The  built-in  constant  $NULL  defines  a  null  pointer. 
Data  Structures 


E  provides  a  mechanism  for  grouping  related  variables  into  data 
structures: 


STRUCTURE  structurename 
GROUP  groupname 

FLT  variablename 


ENDSTRUCTURE ; 


An  arbitrary  number  of  groups  may  be  defined.  The  keyword  LIKE  may 
be  used  to  indicate  that  a  group  is  Identical  to  another  group  or  a 
structure  identical  to  another  structure. 

When  a  variable  that  has  been  declared  inside  a  data  structure  is 
used  in  code,  it  must  be  qualified  with  the  name  of  the  structure 
(and  the  name  of  the  group,  if  needed  to  resolve  ambiguity): 


When  groups  are  manipulated  as  a  unit,  the  GROUP  keyword  may  be 
included  as  an  aid  to  the  reader: 


CALL  COMPUTE 

INPUT  (GROUP  SVECT.radar_re ports) ; 


Expressions 

15  assumes  the  existence  of  the  usual  repertoire  of  built-in 
functions  (ABS,  SIN,  SIGN,  . ..).  Within  logical  expressions, 
logical  operators  are  of  the  form  LE,  LT,  GE,  and  so  on. 

B.4  FLOW-OF-CONTROL  CONSTRUCTS 

IS  uses  a  set  of  flow-of-control  constructs  that  incorporates 
structured  programming  principles.  Readers  familiar  with  othe 
pseudolanguages  are  once  again  reminded  Chat  indentation  counts. 

IF-THEN-ELSE 

This  is  the  usual  conditional.  The  ELSE  clause  is  optional  (but 
recommended  in  complex  statements).  Since  readers  will  presumably 
be  familiar  with  the  syntax  of  this  construct,  the  example  below  is 
meant  to  emphasize  the  effects  of  Indentation. 


This  is  the  multiple-choice  conditional  (like  SELECT-CASE  in  other 
languages).  The  conditions  are  mutually  exclusive.  If  all  the 
logical  tests  fail,  the  optional  OTHERWISE  clause  is  executed. 


LOOP-EXITIF-ENDLOOP 


This  construct  provides  a  good  general-purpose  looping  mechanism. 


LOOP; 

Si; 

EXITIF  (condl); 

S2; 

ENDLOOP; 


In  some  cases,  low-level  operations  within  the  three  looping 
constructs  (such  as  obtaining  the  next  element  in  a  linked  list) 
will  be  omitted  for  brevity. 


C-2 


FUNCTION 


FUNCTION 
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PL/I  BUILT-IN  FUNCTIONS  USED  IN  CMS 


The  following  PL/I  built-in  functions  are  used  in  the  CMS  software: 


ABS(X)  -  ABS  returns  the  absolute  value  of  a  given  expression  X. 

ADDR(X)  -  ADDR  returns  a  pointer  value  that  identifies  the  location 
at  which  a  given  variable  X  has  been  allocated. 

CEIL(X)  -  CEIL  returns  the  smallest  integer  greater  than  or  equal  to 
a  given  value  X. 

FLOAT(X)  -  FLOAT  returns  the  floating  point  representation  of  a 
given  value  X. 


FLOOR(X)  -  FLOOR  returns  the  largest  Integer  less  than  or  equal  to  a 
given  value  X. 


INDEX(Xj,  X2)  -  INDEX  returns  a  halfword  binary  integer 

indicating  the  starting  position  within  the  string  X, 
substring  identical  to  string  X2* 


of  < 


MOD  (Xjl,  X2)  -  MOD  returns  the  smallest  non-negative  value,  R, 
such  that: 


(Xj  -  R)/X2  ■  n  where  n  is  an  integer. 

SUBSTR(X^,  X2,  X3)  -  SUBSTR  returns  a  substring  of  the  given 
string  X^. 

X^  -  string  from  which  the  substring  is  to  be  extracted. 

X2  -  an  expression  that  can  be  converted  to  integer  indicating 
the  starting  position  of  the  substring  in  X^. 

X3  -  an  expression  that  can  be  converted  to  integer  specifying 
the  length  of  the  substring  in  Xj_. 

TIME  -  TIME  returns  a  characterstring  of  length  nine,  in  the  form 
hhmmssttt,  where: 
hh  -  the  current  hour 
mm  -  number  of  minutes 
88  -  number  of  seconds 
ttt  -  number  of  milliseconds 


TRANSLATE (X^ ,  X2,  X3)  -  TRANSLATE  returns  a  string  the  same 

length  as  a  given  string  Xj_,  where  all  or  some  of  the 
characters  may  have  been  changed.  Characters  are  changed 
according  to  a  look-up  table  provided  by  strings  X£  and  X3. 

VERIFY  (X3,  X2)  -  VERIFY  returns  a  default  precision  fixed  point 

binary  integer  indicating  the  position  in  the  given  string  X^ 
of  the  first  character  or  bit  that  is  '.ot  in  the  given  string 
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DATA  BASE  FORMAT 


This  appendix  presents  the  format  associated  with  the  CMS  data 
base.  Figure  E-l  contains  the  CMS  data  base  as  follows: 

o  Line  A  -  Times  at  which  data  from  each  screen  was  stored. 

Times  are  expressed  in  hours  and  minutes, 
Greenwich  Mean  Time  (format:  A4). 

o  Line  B  -  Midway  flag  for  both  current  and  forecast 
versions  of  airport  status  screen  (format  2A2); 
configuration  index,  current  and  forecast 
(format  2F);  departure  queue  lengths  for  up  to 
four  runways  in  both  numeric  and  character  forms 
(format  4A2  and  4F2.0). 

o  Line  C  -  Crosswind  and  tailwind  thresholds,  in  knots,  in 

both  numeric  and  character  form  (format  4A4  and 
4F4.1). 

o  Line  D  -  Airport  status  screen  replica  for  both  current 

and  forecast  conditions  in  character  form 

(format  A). 

o  Line  E  -  airport  status  screen  information  for  both 

current  and  forecast  conditions  in  numerical  form 
(format  8F6.1). 

o  Line  F  -  Equipment  status  screen  replica  for  both  current 
and  forecast  conditions  in  character  form 

(format  A). 

o  Line  G  -  Current  demand  profile  screen  information  in 

character  format  (format  13A4) . 

o  Line  H  -  Forecast  demand  profile  screen  information  in 

character  form  (format  13A4). 

o  Line  I  -  Current  and  forecast  demand  profile  screen 

information  in  numerical  form  (format  26F3.1). 

o  Line  J  -  Equipment  planning  log  screen  replica  in 
character  form  (format  A). 
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FIGURE  E-1 
DATA  BASE  FORMAT 
(CONCLUDED) 


o 


Line  K  -  OTS  and  RTS  values  of  equipment  planning  log 
screen  in  numerical  form  (format  30F4.0).  These 
values  represent  times  in  hours  and  minutes,  GMT. 


o 

Line 

L  - 

Weather  and  wind  planning  log  screen  replica  in 
character  form  (format  A). 

o 

Line 

M  - 

Weather  and  wind  planning  log  screen  information 
in  numerical  form. 

o 

Line 

N  - 

Runway  surface  conditions  planning  log  screen 
replica  in  character  form  (format  A). 

o 

Line 

0  - 

Runway  surface  conditions  planning  log 

information  in  numerical  form  (format  13F4) . 

o 

Line 

P  - 

Demand  planning  log  information  in  character 

form.  The  first  column  represents  time  (GMT); 
the  next  two  columns  are  total  arrival  demand  and 
total  departure  demand,  respectively,  for  that 
hour.  Arrival  demand  data  for  each  of  the  four 
principal  arrival  fixes  is  shown  in  the  next  four 
columns,  followed  by  departure  demand  for  each  of 
the  four  departure  directions. 

o  Line  ?  -  Demand  planning  log  information  in  character  form 
continued. 

o  Line  Q  -  Demand  planning  log  information  in  numerical  form. 

In  addition  to  the  CMS  data  base,  there  are  several  CMS 
permanent  data  files  that  are  read  into  the  memory  at  the  time 
of  the  program  execution.  Each  of  these  permanent  data  files  is 
read  into  a  data  structure  designated  to  that  file.  In  order  to 
obtain  the  format  of  these  files,  it  suffices  to  look  at  the 
description  of  the  data  structure  associated  with  that  file. 
These  data  structures  are  described  in  the  Volume  II,  section 
2.1.  The  following  table  serves  as  the  cross-reference  between 
CMS  permanent  data  files  and  their  data  structures. 


FILE 

DATA  STRUCTURE 

LOCATION 

CAPACITY 

CAPFILE 

Page  2-5 

TRAVEL 

FIXTRAV 

Page  2-5 

RNWYMIN 

RWYMIN 

Page  2-6 

CNFGREQ 

CNFGRQ 

Page  2-3 

OAGDMND 

GAGDEM 

Page  2-4 

DEPEND 

DEPMAT 

Page  2-5 
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